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METHOD AND SYSTEM FOR IMPLEMENTING AN INTER -WORKING 
FUNCTION 

FIELD OF TEE INVENTION 

The present invention relates to telecommuni- 
cation systems. In particular, the present invention 
relates to a novel and improved method and system for 
xmplementing a protocol inter- working function into an 
existing network structure. 

BACKGROUND OF THE INVENTION 

In the current specifications of the third 
generation mobile networks (referred to as UMTS) , the 
system utilises the same well-known architecture that 
has been used by all main second generation systems. A 
block diagram of the system architecture of the cur- 
rent UMTS network is presented in figure I. The UMTS 
network architecture includes the core network (CN) , 
the UMTS terrestrial radio access network (UTRAN) . and 
the user equipment <UE) . The core network is further 
connected to the external networks, i.e. the Internet, 
PSTN and/ or ISDN and/ or other public land mobile net- 
work (PLMN) . 

The UTRAN architecture consists of several 
radio network subsystems (RNS) . The RNS is further di- 
vided into the radio network controller (RNC) and sev- 
eral base stations (BTS, referred to as Node B in the 
3GPP specifications) . The RNCs may have two separate 
logical roles with respect of the connection of UE. 
The RNC is called Serving RNC (SRNC) when it termi- 
nates the both the Iu link for the transport of User 
data and corresponding RANAP signalling to/from the 
CN. SRNC has also other tasks, including radio re- 
source management operations. Drift RNC (DRNC) is any 
RNC other than SRNC that controls the cells used by 
the UE. DRNC is connected to the SRNC by lur inter- 
face. 
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In this architecture there are several dif- 
ferent connections between the network elements. The 
Iu interface connects CN to UTRAN. The lur interface 
enables the exchange of signalling information between 
5 two RNCs. There is no equivalent interface to lur in 
the architectures of the second generation mobile net- 
works. The signalling protocol across the lur inter- 
face is called the radio network subsystem application 
part (RNSAP) . The RNSAP is terminated at both ends of 

10 the lur interface by an RNC „ The Iub interface con- 
nects an RNC and a Node B. The Iub interface allows 
the RNC and Mode B to negotiate about radio resources, 
for example, to add and delete cells controlled by 
Node B to support communication of dedicated connec- 

15 tion between HE and SRNC, information used to control 
the broadcast and paging channels, and information to 
be transported on the broadcast and paging channels - 
One Node B can serve one or multiple cells, ue is con- 
nected to Node B through the Uu radio interface. UE 

20 further consists of a subscriber identity module 
(USIM) and mobile equipment (ME) - They are connected 
by the Cu interface . Connections to external networks 
are made through Gateway MS C (towards circuit switched 
networks) or GGSN (towards packet switched networks) . 

25 The CN (GSM CN) architecture comprises HLR 

(Home Location Register) that is a database for stor- 
ing the master copy of the user's service profile. HLR 
also stores the UE location on the level of MSC/VLR 
(Mobile Services Switching Centre / Visitor Location 

30 Register) and/or SGSN. In figure 1 the CN also com- 
prises MSC/VLR that is the switch (MSC) and database 
(VLR) that serves UE in its current location for cir- 
cuit switched services. 

The general protocol model for UTRAN Inter- 

35 faces is depicted in figure 2, and described in detail 
in the following. The structure described is based on 
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che principle that the layers and planes are logically 
independent of each other. 

The Protocol Structure consists of two main 
layers, Radio Network Layer (RNL) and Transport Net- 
5 work Layer (TNL) . These are presented in the horizon- 
tal planes of figure 2. All UTRAN related issues are 
visible only in the Radio Network Layer, and the 
Transport Network Layer represents the standard trans- 
port technology that is selected to be used for UTRAN 
10 but without any UTRAN- specific changes. UTRAN has cer- 
tain specific requirements for TNL For instance, the 
real time requirement, i.e. the transmission delay has 
to be controlled and kept small. 

The Control Plane includes the Application 
15 Protocol, i.e. RANAP (RANAP, Radio Access Network Ap- 
plication Part) , RNSAP ( RNSAP , Radio Network Subsystem 
Application Part) or NBAP (NBAP, Node B Application 
Part) , that is a part of RNL, and the Signalling 
Bearer, that is a part of TNL, for transporting the 
20 Application Protocol messages. 

The Signalling Bearer for the Application 
Protocol may or may not be of the same type as the 
Signalling Bearer for the ALCAP (ALCAP, Access Link 
Control Application Part) . ALCAP is a generic name to 
25 indicate the protocol (s) used to establish data trans- 
port bearers on the lu. Iur and Iub interfaces, AAL2 
Signalling protocol Capability Set 2 (ITU-T Q. 2630.2, 
a.k.a. Q-aal2 CS-2) is the selected protocol to be 
used as ALCAP in UTRAN. 2630. 2 adds new optional ca- 
30 pabilities to Q. 2630.1 that is used in the first re- 
lease of UTRAN. 

The ITU-T Recommendation Q. 2630. 2 AAL type 2 
Signalling Protocol (Capability Set 2) specifies the 
inter-node protocol and nodal functions that control 
35 AAL type 2 point-to-point connections, AAL type 2 
means ATM adaptation layer type 2 (AAL2) which is an 
ATM adaptation layer that supports variable bit rate. 
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connection-oriented, time -dependent data traffic. Fig- 
ure 3 is showing an example of the use of Q. 2630. 2 in 
the UTRAN context, for the different interfaces. 

In the future the Internet Protocol (IP) is 
5 introduced as an transport protocol for radio accees 
networks (RAN) . So called IP RAN will introduce IP 
base stations (IP BTS or IP BS) that will replace in 
many operations the RNCs of earlier UTRAN releases, IP 
RANs may be connected to other RANs including UTRAN 

10 and GERAN by gateways or servers or the connections 
may be done directly from the IP BTSs, The IP based 
RAN has also been developed by 3 GPP, 

In Release 5 of the 3GPP 3G system (UMTS) the 
IP transport is introduced as an option to ATM/AAL2 . 

15 ATM/AAL2 is the only transport technology in UTRAN in 
former releases, i.e. in Release 99 and in Release 4. 
The work on specifying the Release 5 IP transport is 
currently ongoing and the target for its completion is 
12/2001. The ongoing work and its results are docu- 

20 mented in TR25.933 . 

Along with the introduction of a new trans- 
port option there is a need to ensure that the new and 
the existing technologies can co- exist and inter-work. 
This is considered crucial both from the operators' 

25 network evolution viewpoint as well as from the ven- 
dors' business point of view. 

Also it is emphasised that the inter-working 
between the ATM/AAL2 and IP transport should be real- 
ised and implemented in such a way that the changes to 

30 the existing Rel99 and Rel4 technology and specifica- 
tions are minimal and the inter-working "overhead" to 
the new technology is also limited. 

The objective of the present invention is to 
provide a method for managing an inter- working func- 

35 tion (IWF) in an ATM transport network. Specifically 
the objective of the present invention is to provide a 
useful mechanism for implementing an inter- working 
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function such that a new transport protocol can be 
used in the interface of an existing network structure 
and a new structure or element. Furthermore/ the ob- 
jective of the present invention is to provide such an 
5 implementation that the changes to the existing tech- 
nology, e.g, to the technology according to the above 
mentioned releases 99 and 4 and their specifications 
are minimal and the inter-working "overhead" to the 
new technology is also minimised. 
10 The invention is characterised by what is 

disclosed in the independent claims. 

SUMMARY OF THE INVENTION 

The area of the invention belongs to the 

15 transport technologies in RAN. There are two transport 
technologies in use in the transport networks (do- 
mains) and the Network Elements in these two different 
domains need to be able to communicate with each 
other. It is to be noted that the number of the trans- 

20 port technologies is not restricted to two. 

The baseline for the invention is that the 
existing ATM/AAL2 network and its 3GPP specifications 
should be left untouched as much as possible. In RAN 
based on ATM/AAL2 transport there is AAL2 Signalling 

25 used as ALCAP. 

Further the invention is based on the idea 
that the existing AX.CAP, e .g. Q. 2630 is used hot only 
in the ATM/AAL2 domain as an ALCAP , i.e. no changes to 
the existing specifications, but also as an auxiliary 

3 0 control protocol in the ip transport domain. This is 
accomplished by using a user defined information ele- 
ment of said existing ALCAP . This is to say that what- 
ever the ALCAP is, it has to have some information 
element the content of which can be determined by the 

35 served user. In one example it is implemented by ex- 
tending the capabilities of Q.2630 by utilising its 
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Served User Transport (SUT) Information Element. The 
SUT is an optional information element in the Estab- 
lish request message of Q.2630 that can convey any in- 
formation transparently from one AAL2 served user to 
5 another (the peer AAL2 served user} - According to the 
above mentioned recommendations the length of the SUT 
is 1-254 octets. In the present invention the SUT 
transparently conveys all IP transport related infor- 
mation between the peer Q.2630 entities in the net- 
10 work. 

The benefits of the invention can be summa- 
jrieed as follows. Whfen. implementing a new type of 
transport layer protocol, there is no need for a new 
ALCAP protocol. Instead of it the existing ALCAP, i.e. 

15 Q.2630 in one example can be used also in the new pro- 
tocol, e.g. IP, side. Signalling bearer for Q.2630 
over IP xs already available in Release 99. Further 
only a subset of an existing ALCAP (Q.2630) needs to 
be implemented in the IP based RAN nodes, thus reduc- 

20 ing the inter-working overhead there, and only minor 
changes in the existing ATM/AAL2 network Elements are 
needed. 

Further there is no need for Radio Network 
Layer inter -working as the standard RANAP/RNSAP/NBAP 
25 without any new Information Elements can be used. In- 
ter-working function can be implemented and used 
solely in the transport Network -Layer. Neither there 
is heed to know the type of the neighbouring RAN node 
(IP/ ATM) in advance. The type is implicitly determined 
from the type of its transport layer address informa- 
tion, resulting either in native operation or opera- 
tion with the TNL IWF. Also, thanks to the invention 
there is no restrictions in the location of the inter- 
ior king Function (IWF) but it can be either a standa- 
35 lone node or a part of any RAN or IP RAN node. The in- 
vention will make it easier to inter-work between dif- 
ferent radio access networks. 
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BRIEF DESCRIPTION OP THE DRAWINGS 

The accompanying drawings, which are included 
to provide a further understanding of the invention 
and constitute a part of this specification, illus- 
trate embodiments of the invention and together with 
the description help to explain the principles of the 
invention- In the drawings: 

Pig 1 is a block diagram illustrating an ex- 
ample of the state of the art scenario relating to the 
present mobile network; 
15 Fig 2 is a general protocol model for UTRAN 

interfaces of figure i. 

Fig 3 is a signalling diagram illustrating an 
example of the use of Q. 2630. 2 in the UTRAN context; 

Fig 4 is a block diagram that describes one 
20 embodiment of the present invention and; 

Figs 5a- 5b constitute a signalling diagram 
describing one embodiment of the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 

25 Reference will now be made in detail to the 

embodiments of the present invention, examples of 
which are illustrated in the accompanying drawings. 

- In the following, four different use examples 
for the present invention are described. The examples 

30 are related to the possible inter-working cases in the 
present scenario of the ATM based UTRAN network. It is 
to be noted that these examples are presented relating 
to the UTRAN and AAL2 (Q.2630) signalling as an ALCAP, 
and assuming that the new protocol would be IP. How- 

35 ever, the invention is not to be restricted to these. 
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In the figure 4 is illustrated involved AAL2 
served users and their logical location there accord- 
ing to one embodiment of the present invention- In 
figure 4 the left side represents the ATM/AAL2 domain 
5 and the right side the IP domain. In the middle is the 
Inter- working Function IWF. The IWF can be implemented 
as a standalone node or as part of any other network 
node for example IP BTS, RNC, some gateway or server,. 

The communication in ALCAP. i.e. Q.2630 in 

10 this example goes always via the IWF- That is, the IWF 
terminates the Q. 2630 from both sides and is acting as 
an AAL2 served user- The Radio Network Layer signal- 
ling does not have to go via the IWF at all. This is 
one of the benefits of the present invention. 

* 5 On ATM/AAL2 side the Q.2630 is used exactly 

in the same way as it has been specified in 3GPP UTRAN 
specifications so far. On IP side only the SUT (Served 
User Transport) Information Element and its contents 
as well as the Binding ID (B-ID) are relevant for the 

20 UTRAN IP node. The term Sig bearer in figured denotes 
to signalling bearer of the ALCAP and it is specified 
in the above mentioned specifications. The notations 
LI and L2 refer to terms layer 1 and layer 2, corre- 
spondingly. 

25 In the following more detailed description of 

the special cases of the invention is given. In this 
example the embodiments of the invention cover the 
following cases; 

Connection Establishment / Release on lur 

30 from the ATM/AAL2 domain towards the IP domain. 

Connection Establishment / Release on lur 
from the IP domain towards the ATM/AAL2 domain. This 
is also presented in the signalling diagram of figures 
5a and 5b. 

35 Connection Establishment / Release on lub 

from the ATM/AAL2 RNC to IP Base Station 
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Connect ion Establishment / Release on lub 
from the IP RNC to ATM/AAL2 Base Station 

It is also to be noted that on lur interface 
the transport bearer is always established by the 
5 Serving RNC of the given context . So in physical sense 
the lur establishment can start from either end of the 
lur. On lub the transport bearer is always established 
and released by the Controlling RNC. The Node B is 
never establishing nor releasing the lub transport 
10 bearer. These principles are according to 3GPP Speci- 
fications 

In the first example SRNC on ATM/AAL2 domain 
starts the transport channel setup by sending the cor- 
responding RNSAP message on Radio Network Layer. Then 

15 the Drift RNC is expected to respond by sending the 
RNSAP Response message. The response includes the 
needed transport information like destination IP ad- 
dress and the UDP port. In addition the Binding ID is 
included. The transport information is checked by the 

20 SRNC and when the destination address is other than an 
ATM End System Address (AESA) , the SRNC application 
logic determines that IWF is needed. The IWF is found 
by either using a default IWF (per RNC, per physical 
signalling interface or per logical signalling inter- 

25 face) or by performing a search for the IWF based on 
the address information. That is, there can be a map- 
ping table in the SRNC where there is an entry (IWF 
address (AESA) ) for each IP RNC .■ The IWF information 
can also be in a centralised location somewhere in the 

30 network, accessed by each RNC similarly as domain name 
server (DNS) queries are done in IP world. The infor- 
mation the SRNC needs is the routable address of the 
IWF, For an RNC having only ATM/AAL2 interfaces this 
address needs to be an ATM End System type of address. 

35 When the IWF address is found, the Al,CAP of 

SRNC sends a normal Q.2630 Establish Request (ERQ) 
message towards the IWF. The optional Served User 
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Transport IE is now included and it contains the 
transport address information that was originally re- 
ceived from the DRNC. When the IWF receives the ERQ, 
it checks the SUT and finds the IP transport infonna- 
5 tion. IWF makes the mapping between the AAL2/ATM in- 
terface and the IP interface and allocates the needed 
resources. Then the ALCAP in the IWF sends an ERQ 1 to- 
wards the DRNC . The ERQ' represents a normal Establish 
Request except that the Connection Endpoint informa- 

10 tion may be null. The SUT contains now the destination 
address and UDP port of the IWF (the port that is used 
by the IWF to receive the data from the DRNC side. The 
binding ID (B-ID) is conveyed in the Served User Gen- 
erated Reference (SUGR) IE in the normal way. The B-ID 

15 is the one that was originally allocated by the DRNC . 
The signalling address of the DRNC is determined by 
the IWF based on a default address or according to the 
IP address information of the DRNC (received in the 
SUT of ERQ from SRNC) . The DRNC identifies the re- 

20 ceived ERQ' by its Binding ID. The DRNC sends an ac- 
knowledgement ( ECF 1 } back to IWF . Then the IWF sends 
the Q.263Q Establishment Confirm (ECF) message back to 
SRNC. From the SRNC viewpoint there is now a transport 
bearer between the SRNC and the DRNC. 

25 The transport bearer release is by default 

done by the SRNC as well. On the IP side of the IWF 
there is no need for any TNL signalling message ex- 
change. On the ATM/AAL2 side the release is done ac- 
cording to Q.263 0, initiated by the RNC. The IWF re- 

3 0 leases the AAL2 connection resource and clears the 
through connection and the IP address & UDP port. The 
RNC on IP side functions similarly as in the all-IP 
case (i.e., no IWF); the connection resource is re- 
leased based on the RNL signalling transaction- The 

35 Binding ID is not needed nor used here. 

When the transport channel is established 
from the IP side of the lur, see figur s 5a and 5b, 
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the message sequence in RNL is exactly as it is in any 
other case. Now the SRNC starts the procedure by send- 
ing a radio link reconfiguration request to DRNC , The 
DRNC in ATM/AAL2 side sends the Rnsap response message 
to SRNC and it contains all the necessary transport 
information (B-ID, AESA) as specified in RNSAP speci- 
fication [TS25.423 V3.00 (Rel99) and v4.0Q (Rel4) ] . 
When the SRNC on IP side founds out that the type of 
the transport address is not IP, it determines that 
the IWF is needed. The involved IWp (its address) is 
found in one of the ways described in the first case 
above (RNC) . when the IWF is found < its signalling ad- 
dress) the ERQ 1 is sent to it (Q.2630 over SigTran) . 
ERQ' contains the Sut IE conveying the destination IP 
address and the UDP port of the SRNC and the SUGR IE 
conveying the B- ID originally assigned by the DRNC and 
the A2EA conveying the AESA of the DRNC. As soon as 
the IWF receives the ERQ p it starts the connection es- 
tablishment cowards the DRNC (in ATM/AAL2 domain) by 
sending out the regular Q.26 3 0 ERQ with the 8- ID and 
AESA copied from the ERQ 1 - DRNC then responds by send- 
ing the ECFbacJc to IWF. When EFC is received it trig- 
gers the IWF to send ECF' back to SRNC. This ECF 1 is a 
regular ECF but with sut [Note: this is the only 
change needed in 2630]. SUT conveys the IP address 
and upp port of the IWF. 

The transport bearer release is done by send- 
ing a Q . 263b Release message (REL 1 ) from SRNC (IP) to 
the IWF. Based on the received REL 1 the IWF clears the 
trough- connect and IP resources and sends a REL to 
DRNC according to Q. 2630 release procedure. 

On Iub all connection transport bearer con- 
trol actions are initiated by the Controlling RNC of 
the given Base Station (BS) . The transport bearer es- 
tablishment xs started as soon as a NBAP response is 
received from the BS by the RNC. The response (to the 
originally sent NBAP Setup Request) contains the 
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transport: layer information (Binding ID, IP address 
and UDP port) . The RNC detects then a non- AESA ad- 
dress and determines that an IWF is needed. The cor- 
rect iwf is found as described in case X. Then che 
ALCAp in RNC sends out the Q. 2630 ERQ towards the IWF 
with SUT IE containing the IP transport information. 
SUGR containing the B-ID, etc. Receiving IWF then 
sends the ERQ' to BS with SUT containing the IP ad- 
dress and UDP port of the IWF. The BS acknowledges by 
sending the ECF' back to IWF. Then the iwf responds to 
RNC by sending a normal ECF to it. 

The connection is released similarly as in 
case the first case. There is no ALCAP signalling 
needed in TNL on the IP side of the IWF. 
15 The RNC with IP interface receives the NBAP 

respond from the BS conveying an AESA type transport 
address. It indicates that an IWF is needed. IWF is 
then found and the RNC sends an ERQ' towards the IWF 
with sut conveying the IP address and the udp port of 
20 the RNC . SUGR conveys the B-ID. CEID is null as it is 
not needed in the IWF. When IWF has received the ERQ 1 , 
it starts a normal Q. 2630 connection establishment to- 
wards the BS using the B-ID received in ERQ'. As soon 
as an ECF is received from the BS, IWF sends ECF ' to 
25 RNC, including the SUT containing the IP address and 
UDP port of the IWF. 

The transport bearer is released by the RNC 
similarly as in the second case. 

It is obvious to a person skilled in the art 
30 that with the advancement of technology, the basic 
idea of che invention may be implemented in various 
ways and in various network environments The invention 
and its embodiments are thus not limited to che exam- 
ples described above, instead they may vary within the 
35 scope of the claims. 
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CLAIMS L & 

1. A method for controlling an inter-working 
function linked with an ATM transport network, 
characterised in that said inter-working 
function uses a user defined information element of an 
existing protocol, that is used for establishing the 
data transport bearers, to adapt a new protocol for 
controlling the transport bearers in the Transport Net- 
work Layer. 

2. The method according to claim 1, char- 
acter! s e d in that said ATM transport network is 
used in Radio Access Network; and that said existing 
protocol is ALCAP protocol based on AAL2 Signalling. 

3. The method according to claim 2, char- 
15 acterised in that said AAL2 signalling is based 

on ITU Recommendation Q.2630. 

4. The method according to claim 3, char- 
acterised in that as said user defined informa- 
tion element of an existing ALCAP protocol is utilised 
a Served user Transport (SUT) Element of said Q.2630 
signalling. 

5. The method according to claim 1. char- 
acterised in that using said user defined infor- 
mation element in said new protocol for conveying in- 

?5 formation needed by said existing ALCAP protocol. 

» * 

6. The method according to claim 1, char- 
act e rise d in that including said user defined 

} information element in the Establish Confirm message of 
i said existing ALCAP protocol. 

7. The method according to claim 2, c h a r - 
••. acterised in that when receiving an address in- 
formation of an Radio Access Network node, 

the check is made whether said address infor- 
mation is compatible with an address space of receiv- 
es ing protocol, and if said address information is not 
compatible, 

• • 

if the address of said inter-working function is 

.. : determined, 
♦ 

'•: 8 - T he method according to claim 7. c h a r - 

•.4|0 acterised in that the address of said inter- 
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working function is determined by default for 

each network node . 

9. The method according to claim 7. char- 
acterised in that the address of said inter- 
working function is queried from a centralised location 
in said network, 

10. The method according to claim 7, 
characterised in that the address of said in- 
ter-working function is determined based on a physical 
port from which Application Protocol message was re- 
ceived. 

11. The method according to claim 7, 
characterised m that the address of said in- 
ter-working function is determined based on a logical 

15 port from which Application Protocol message was re- 
ceived. 

12. The method according to claim 7, 
characterised in that said check is made us- 
ing a type of address information field that indicates 

20 at least one of the following set including, the type 
of a network node, a type of address and a type of 
Transport Layer. 

13. The method according to claim 7, 
characterised in that said check is made us- 

25 ing a type of node information field that indicates at 
least one of the following set including, the type of a 
network node, a type of address and a type of Transport 
Layer. ■■ 

op l 14. The method according to claim 7, 

,.?30 c h a r a c t e r i s e d in that said check is made us- 
• Sj ing a type of transport layer information field that 
indicates at least one of the following set including, 
the type of a network node, a type of address and a 
**: type of Transport Layer. 

][i 3S 15- The method according to claim 1, 

characterised in that mapping between the 
^ first interface of said existing protocol and the sec- 

... # ond interface of said new protocol is made in said in- 
•J ter-working function based on information in said user 
m J40 defined element. 

16. The method according to claim i, 
characterised in that said inter-working 
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fvinction is implemented as a stand-alone node in said 
ATM transport network. 

17. The method according to claim l, 
characterised in that said inter-working 
5 function is implemented as a stand-alone node in a 
transport network. 

IS. The method according to claim l, 
characterised in that said inter-working 
function is implemented as a part of a network node in 
10 said ATM transport network. 

19. The method according to claim i, 
characterised in that said inter- working 
function ie implemented as a part of « network node in 
a transport network. 
15 20 • The method according to claim 17 or 19, 

characterised in that said transport network 
is based on IP network. 

21. A System for controlling an inter-working 
function linked with an ATM transport network, 

20 characterised in that said inter-working 
function comprises 

a mapping entity that is arranged to use a 
user defined information element of an existing proto- 
col, that is used for establishing the data transport 
bearers, to adapt a new protocol for controlling the 
transport bearers in the Transport Network Layer. 

22. The system according to claim 21, 
char a C t e r i s e d in that said ATM transport net- 
work is used in Radio Access Network; and that said ex- 

-30 isting protocol is ALCAP protocol based on AAL2 Signal- 
ling. 

23. The system according to claim 22, 
characterised in that said AAL2 signalling is 

** : based on itu Recommendation Q.2630. 

: . 35 24 • The system according to claim 23, 

characterised in that as said user defined 
information element of an existing protocol is utilised 
a Served User Transport (SUT) Element of said Q.2630 

'.: signalling. 
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25. The syscem according to 

claim 21, characterised in that the system 

further comprises 

a checking entity for making a check whether 

an address information is compatible with an address 

space of receiving protocol, when receiving an address 

information of an Radio Access Network node; and 

an address determining entity for determining 

the address of the said inter-working function 
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(57) ABSTRACT 

The area of the invention belongs to the 
transport technologies in UTRAN. There 
are two transport technologies in use in 
the transport networks (domains) and the 
Network Elements in these two different 
domains need to be able communicate with 
each other. The baseline for the inven- 
tion is that the existing ATM/AAL2 net- 
work and its 3gpp. specifications should 
be left untouched as much as possible. 
In UTRAN based on ATM/AAL2 transport 
there is AAL2 Signalling used as ALCAP. 
the invention is : based on the idea that 
the existing ALCAP. e.g. -Q. 2.630 is used 
not only in the ATM/AAL2 domain as an 
ALCAP, i.e. no changes to the existing 
specifications, but also as an auxiliary 
control protocol in the IP transport do- 
main. This is accomplished by using a 
user defined information element of said 
existing ALCAP. 
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